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EASING THE SOFTWARE MAINTENANCE BURDEN 


Software maintenance still requires a significant portion 
of programmers and analysts’ time, in most data process- 
ing departments. But perhaps because software mainte- 
nance tends to be viewed as an uninteresting, necessary 
evil, it often appears that nothing can be done to reduce 
this workload. And, in fact, a 1978 survey showed little 
change in the overall maintenance workload during the 
1970s. This month we look at software maintenance to see 
whether there are any new ideas on how to ease this main- 
tenance burden. We begin by describing three different 
approaches taken by three companies for creating more 


maintainable systems. 


The Monsanto Company, with head- 
quarters in St. Louis, Missouri, is a leading 
manufacturer of textiles, chemicals, 
plastics, resins, and agricultural products. 
Annual sales exceed $6 billion, and the 
company employs about 64,000 people. In 
its central data processing facility in St. 
Louis, Monsanto uses large scale IBM 
computers. 

In the late 1970s Monsanto began study- 
ing their need for a corporate-wide medi- 


cal and environmental health information 


system (MEHI). On a joint venture with 
IBM, they identified seven major compo- 
nents. Three are: a materials system that 
contains information about all of the ma- 
terials (both raw and manufactured) that 
Monsanto uses, an occupational exposure 
system that lists all employees and the sub- 


stances they are exposed to in their work 
at Monsanto, and an emergency system 
that lists which employees to contact for 
each identifiable emergency and how the 
company could respond to these emergen- 
cles. 

For the first sub-system to be developed, — 
the materials system, Monsanto chose to 
use IBM’s conversational Application De- 
velopment Facility (ADF). The prime value 
of ADF, in Monsanto’s eyes, would be in 
reducing development time. But a signifi- 
cant side benefit has been in decreasing 
program maintenance. Although ADF is 
not as efficient to run as, say, COBOL pro- 
grams, Monsanto felt that with the ex- 
pected low processing volume of the ma- 
terials system, ADF would perform satisfac- 
torily, so its use appeared cost justified. 
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ADF is an IBM application development tool 
for helping programmers create IMS/VS applica- 
tions—applications which use IBM’s IMS data- 
base management system under the VS operating 
system. ADF offers a conversational mode, a non- 
conversational mode, and a batch mode. 

Creation of an ADF program is quite different 
from conventional programming. The program- 
mer does not create a program per se. Rather 
he/she specifies parameters for common mod- 
ules. Hand-coded subroutines also can be added. 
The parameters are stored in certain databases; 
data used by the application is stored in other 
databases. At execution time, ADF invokes the 
common modules in a pre-programmed order, 
and combines them to create a distinct program. 
(For more information on ADF, contact your lo- 
cal IBM sales office.) 

Monsanto chose conversational ADF for its on- 
line materials system for several reasons. First of 
all, the security option, which was a major con- 
cer, was adequate and involved significantly 
less work to set up than would a COBOL IMS pro- 
gram. In addition, changes to the security net- 
work would be a relatively minor task. Second, 
conversational ADF could automatically generate 
menus of data items to aid users in searching a 
database. These two features contributed signif- 
icantly to decreasing the project’s development 
time and costs. The project took nine months 
less time to complete than if it had been written 
in COBOL—and that was a 75-80% reduction in 
programming and test time. An additional ad- 
vantage of conversatonal ADF was that Monsan- 
to’s programmers learned to use it quickly. 

ADF was able to handle thirty-four of the 
forty-seven transaction types required in the ma- 
terials sub-system. For these, programming and 
testing took three days or less per transaction 
type. For the thirteen remaining transaction 
types, which needed to be hand-coded, each 
took six days. 

ADF has also significantly reduced the amount 
of maintenance required by the system. In the 
first twelve months of use, there were no abnor- 
mal program terminations due to programming 
errors; all the things ADF did, it did correctly. So 
Monsanto has had virtually no corrective main- 
tenance on the materials system. 


As for enhancement maintenance, adding new. 
transaction types and new features requested by 
users has been far easier than with COBOL. Mon- 
santo is now using ADF on a second MEHI sub- 
system, because they find that it produces reli- 
able systems and increases their programmers’ 
productivity as well, for both development and 
maintenance work. 


Western Carriers Underwriters 


Western Carriers Underwriters is a four year 
old company that specializes in commercial au- 
tomobile insurance for the transportation indus- 
try. Western Carriers is located in San Berna- 
dino, California, just east of Los Angeles, and 
employs 50 people. Operating through indepen- 
dent agents, in 1980 they had insurance pre- 
mium sales of $8.5 million. 

In late 1979, Western Carriers had (essen- 
tially) a mini-computer, not much software that 
really met their needs, and three people in their 
data processing department—a manager (who 
also does a lot of the programming), a program- 
mer analyst, and a data entry person. Today, a 
year and one-half later, they have the same three 
people, a larger model of the mini-computer, 
and four main-line applications that involve over — 
200 programs with some 500,000 lines of COBOL 
code. 

The computer they now have is a Prime 550 
computer with 1.25 million bytes of internal 
memory plus one 300 megabyte and two 80 
megabyte disk drives, two printers, and eight 
work-stations. But the product that enabled 
Western Carriers to create and maintain so 
much software with so few people is a COBOL 
program generator obtained from David R. 
Black and Associates (see Reference 6). Western 
Carriers obtained the generator in December 
1979, and the two programmers have created 
75% of their software using it. The generator 
provides a data dictionary, a screen formatter, a 
menu generator, and a number of skeleton CO- 
BOL programs for performing the most common 
functions found in business applications. 

For each of the application programs, the 
generator leads programmers through entering 
data definitions and validation rules. To perform 
more elaborate validation checks not provided 
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by the generator, the programmers wrote short 
COBOL routines which they imbedded in the val- 
idation routines created by the generator. 

With the data dictionary filled in, the pro- 
grammer then specifies the data entry screen for- 
mats, reports, and menus, using different facili- 
ties within the generator. 

The generator allows Western Carriers to cre- 
ate new programs quickly. But even more im- 
portantly, it has a greater impact on mainte- 
nance. For one thing, Western Carriers has 
found no coding errors in code generated by the 
program generator, so that most of their pro- 
grams compile completely on the first try. The 
only coding errors are in the code they write to 
supplement the generator’s code. The generator 
can create 70% of the code they need for their 
major programs, and 100% for the ad hoc re- 
quests. 

After using the generator for a year and a half, 
they know how the generator will handle most 
situations, so they know what effect changes will 
have. Also, the generator produces modular 
code, so that changes tend not to spread from 
one module to another. The result thas been that 
Western Carriers has practically no corrective 
maintenance. 

However, they do have enhancement mainte- 
nance. Although they generally do not use the 
generator for making these enhancements, the 
time it takes to perform this maintenance has 
been greatly reduced because of the generator. 
The generator creates programs using a standard 
format, so the programmers often do not need to 
print out a listing in order to figure out where to 
make the changes. They simply go to a terminal, 
call up the COBOL source code subroutine which 
performs the desired function, and make the 
change. All programs have the same subroutine 
structure and same conventions, so maintenance 
is fast. At first Western Carriers thought that 
standardization was a nice feature. Now they see 
it is the most important feature of the generator, 
especially for maintenance. 

As an example, in January of this year, a 
change in the billing procedure led to a major 
maintenance project. All of the policy number 
fields had to be split into three separate fields, 
which required changes in all programs that use 
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the policy number field. Fortunately, because the 
generator always uses one subroutine to refer- 
ence this key index field, the programmer only 
needed to change this particular subroutine in 
each affected program. So this major mainte- 
nance project was conducted without their need- 
ing to hire more people. 


Since the standard programs allow Western 
Carriers to perform changes so quickly, they 
have been able to respond to management’s and 
end users’ requests for enhancements very rap- 
idly. In fact, the data processing manager has 
had to implement a more formal change control 
procedure to slow down somewhat the requests 
for enhancements. 


The people at Western Carriers are delighted 
that the program generator allows them to have 
a small, efficient data processing operation. They 
estimate that without it, they would probably 
have required seven more people (project man- 
agers and programmers) just to create the sys- 
tems they now have, not to mention maintaining 
them. 


The Arizona Bank 


The Arizona Bank is a full service bank with 
headquarters in Phoenix, Arizona. The bank has 
assets of $2 billion and employs 2200 people in 
91 branches throughout the state. 


Within the past few years, new government 
regulations for the banking industry have 
prompted the bank to offer interest-earning 
checking accounts and new types of loan ar- 
rangements. They have also installed a network 
of automated teller machines and an on-line 
teller and administrative terminal system. These 
operational changes have required their data 
processing department to install a number of 
new, sophisticated systems as well as make ex- 
tensive changes to existing systems. The bank 
has an IBM 3033 and they use IBM’s IMS data- 
base management system. 


For the size of the bank, and the complexity 
of its application systems, The Arizona Bank has 
a small data processing department—only fifty 
programmers and analysts. This is because the 
bank has a policy of buying application packages 
rather than developing systems in-house. Cur- 


rently, 90% of their application software consists 
of purchased packages. 

Only two of their banking applications—in- 
stallment loans and savings—were written in- 
house. These were created more than fifteen 
years ago and are still being used. The rest of 
their banking applications are purchased pack- 
ages. These include the rest of their banking ap- 
plications as well as accounting systems, several 
electronic funds transfer systems, and others. In 
all, the bank uses packages from fourteen ven- 
dors. 

Due to their policy of relying on purchased 
software, the application development cycle at 
the bank differs from the typical software devel- 
opment cycle. Whenever a new system is under 
consideration, a project study team is formed to 
analyze the make-or-buy alternatives. The teams 
work anywhere from one to six months studying 
the alternatives. Due to time and cost considera- 
tions, they almost always recommend purchasing 
an outside package. 

Of particular interest is how this policy of 
procuring purchased packages impacts software 
maintenance. The story really begins with the 
work of the study teams. 


The work of the study teams. The study teams 
generally consist of several people from data 
processing as well as several user representa- 
tives. Members of the team search out packages 
that might fit their needs by using several indus- 
try publications, by attending banking confer- 
ences, and by contacting people they know in 
other banks. Also, and very importantly, they be- 
come involved in vendors’ user groups; often 
they find out about other products at user group 
meetings. In addition, these groups provide users 
with an effective means of requesting (and get- 
ting) enhancements and changes made to the 
vendor's products. This is the best way to get a 
change made by a vendor, we were told. 

Team members are responsible for performing 
specific duties depending upon their areas of ex- 
pertise. For example, the data processing opera- 
tions person evaluates the impact of each alter- 
native upon the bank’s hardware. The IMS per- 
son looks at how much work would be involved 
in interfacing each alternative package to the 
IMS database system. And the user representa- 


tives study the user documentation and functions 
performed by each alternative package. 


Based on management policies, they require 
that they receive from the supplier a package's 
source code, not object or intermediate code, so 
that they can create proper interfaces for the 
package. Also, with some exceptions, they re- 
quire that the application packages be written in 
COBOL. 


When evaluating application packages, one 
important factor that the teams consider is how 
much ‘maintenance’ each package will require. 
Their package maintenance takes several forms: 
(1) adapting a package to the bank’s environ- 
ment, (2) adding desired capabilities that are not 
included in the package, (3) correcting errors, (4) 
installing vendor changes in the future, and (5) 
making user-requested modifications. In particu- 
lar, technical experts on the team try to deter- 
mine how much in-house effort will be required 
to interface each package to their existing data- 
bases and systems. 


The team also identifies required functions 
and features that are not included in each alter- 
native package, and how the deficiencies can be 
remedied—either through in-house modifications, 
vendor-made changes, or a joint bank-vendor 
contract. And the team estimates how much on- 
going support the vendor will supply after the 
package is installed, and how vendor changes 
and updates will be made. 


The bank’s policy is to make as many of the 
changes as possible by creating new stand-alone 
program modules which work with the pur- 
chased software. In this way, the bank is able to 
install new releases of the package without too 
much maintenance work on their part. Most of- 
ten, however, the bank and the vendor perform 
maintenance jointly. 


As a point of interest, the bank’s data process- 
ing people estimate that 50% of the in-house re- 
quests for changes have been for new types of 
reports. Therefore, they look very favorably on 
packages that provide report generator capabili- 
ties with which end users can create their own 
ad hoc report requests. Where such systems 
have been installed, there are fewer user-re- 
quested changes. 
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The Arizona Bank is pleased with its approach 
of purchasing most of its software for several 
reasons. Of most interest, of course, is getting 
applications set up and running more quickly— 
and with perhaps more sophisticated applica- 
tions than they could have developed in-house. 

On the point we were probing—maintenance— 
they have found substantial benefits also. As de- 
scribed, they minimize routine corrective main- 
tenance and concentrate on adapting and en- 
hancing packages. 


Is software maintenance changing? 


Within the past two years, we have seen an 
increasing amount of written material on soft- 
ware maintenance. Of particular interest are 
three books on the subject. Software Mainte- 
nance Management by Lientz and Swanson (Ref- 
erence 1) describes their findings about software 
maintenance from a 1978 survey of 487 compa- 
nies. Techniques for program and system main- 
tenance, edited by Parikh (Reference 2), is a 
compilation of forty papers on the subject of 
software maintenance. And Software mainte- 
nance guidebook by Glass and Noiseux (Refer- 
ence 3) discusses the people, technical, and man- 
agerial aspects of maintenance and presents the 
authors’ views on which techniques and tools 
they have found most helpful for maintenance 
programming. We will reference these three 
books throughout this report. 

In 1978, Lientz and Swanson, professors at the 
University of California at Los Angeles, per- 
formed a study to uncover the characteristics of 
software maintenance, mainly in the business 
data processing environment. 

They found that on the average, software 
maintenance required 45% of systems and pro- 
gramming resources in most companies. This 
figure is about the same as the authors found 
two years earlier in a similar study. And it also 
matches the estimate we gave in our October 
1972 report on maintenance. Therefore, it ap- 
pears that the total maintenance effort is not in- 
creasing, as often reported in the press, nor is it 
decreasing, as predicted by many proponents of 
programming tools. However, in our research 
we did find that the characteristics of mainte- 
nance work have changed for the better, since 
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our 1972 report, where companies have devel- 
oped more maintainable systems. 

To better understand software maintenance, 
consider the definitions created by Lientz and 
Swanson. They divide maintenance into three 
components: corrective, adaptive, and perfective 
(enhancement). 

Corrective maintenance consists of dealing 
with failures in processing, performance or im- 
plementation, such as fixing errors and routine 
debugging. The authors found this type of main- 
tenance generally accounted for about 20% of 
most companies’ maintenance efforts. 

Adaptive maintenance includes responding to 
anticipated changes in the data or processing en- 
vironment. For example, it includes converting 
to a new operating system, responding to 
changes in government regulations, and so on. 
This type of maintenance accounted for about 
25% of the maintenance effort, the authors re- 
ported. 

Enhancement (or perfective) maintenance, re- 
fers to (1) enhancing processing efficiency, per- 
formance, and system maintainability, (2) im- 
proving program documentation, and (3) making 
enhancements for users. This form of mainte- 
nance accounted for the remainder (about 55%) 
of all maintenance work, and almost two-thirds 
of that went toward making enhancements re- 
quested by users—specifically, giving users more 
capabilities. 

In our 1972 issue on maintenance we de- 
scribed some techniques for creating more main- 
tainable systems. We will now review these 
points to see how much impact they have had 
on easing software maintenance. 

In 1972 we recommended designing for 
change by installing software design standards 
and documentation standards. The rationale is 
that if applications are designed using the same 
basic company-wide standards, more people are 
likely to know the standards and therefore be 
able to maintain these applications more easily. 
(A good illustration of this point is the experi- 
ence of Western Carriers Underwriters, de- 
scribed earlier.) 

Since 1972 there has been a lot of activity in 
several of the software design and documenta- 
tion areas. Numerous software design techniques 


have been introduced, each offering its own 
form of standards. Yet at the time of their survey 
(1978), Lientz and Swanson found only three de- 
velopment tools in use in more than 30% of the 
companies. Surprisingly, one was decision tables; 
they were used by 34% of the companies. Chief 
programmer teams were used by 38% and struc- 
tured programming by 30%. The other tech- 
niques mentioned by the authors—HIPO, data 
dictionaries, test data generators, and structured 
walk-throughs—were each used by less than 20% 
of the companies responding. 

Lientz and Swanson found that use of such 
techniques did lead to more maintainable sys- 
tems. They therefore speculate that organiza- 
tions which use such techniques for software de- 
velopment may reduce the amount of corrective 
maintenance that they must perform, because 
there are fewer errors to correct. However, the 
relative ease of making additions and changes to 
these more maintainable programs, and the 
lower risk of creating errors through such 
changes, often encourages users to ask for more 
enhancements. So enhancement maintenance of- 
ten rises. This explains the relatively constant to- 
tal spent on total maintenance, say the authors. 

In 1972 we also suggested installing software 
modification and testing aids, such as cross ref- 
erence listings, on-line editing and debugging fa- 
cilities, standard testing procedures, and general- 
ized data management systems. 

Each of these types of aids is being used, but 
the area in which we are just now seeing increas- 
ing interest is in the last named—the generalized 
data management systems (DMS). Within the past 
few years, these products have been enhanced 
substantially so that they now allow creation and 
modification of files, data definitions, and pro- 
grams. We have discussed these products in 
some detail in recent months, particularly in the 
May, June and July issues. 

One question these DMS raise is: how might 
they affect maintenance work in the data 
processing department? One company we talked 
with has said that although enhancements and 
changes are much easier to make, their backlog 
for such requests has increased. So the same 
thing may occur with the use of DMS as was 
mentioned for structured programming tech- 


niques—that is, corrective maintenance decreases 
but enhancement maintenance increases. 

In 1972 we also suggested establishing data 
processing configuration policies. These consist 
of controlling changes in the organization’s 
hardware, operating systems, utility software, 
and so on. 

There appears to be an interesting phenome- 
non occurring in this area. Companies, by and 
large, have developed configuration policies for 
their mainframe computers. And computer 
mainframe manufacturers and vendors of pro- 
ducts for mainframes are very aware that com- 
panies have large investments in existing appli- 
cations—so they often include “migration tools’ 
when they introduce new hardware and software 
products. 

But what about company-wide configuration 
policies for mini-computers, and even more re- 
cently, for micro-computers? Are users and ven- 
dors worrying much about configuration stan- 
dards and migration tools for these machines? 
The answer appears to be mostly No. We see a 
few user companies trying to establish standards 
and guidelines for these smaller machines. How- 
ever, we also see many companies not really 
worrying about the stand-alone systems that de- 
partments are bringing in on their own. We 
think this second attitude is a mistake. 

While local networks may provide the means 
for connecting incompatible machines, we think 
configuration policies should be created for 
smaller machines for two reasons. One is soft- 
ware portability. Creating software for small 
machines is expensive, so it is wise to exchange 
programs where possible. The second reason is 
for compatibility among data used by several de- 
partments—portable data. 

Companies should also evaluate these smaller 
systems with an eye toward whether they allow 
easy migration to larger machines—not only pro- 
gram migration but also data migration. This 
can be a serious problem, as we discussed five 
months ago (March). Not all small machine ven- 
dors provide easy vertical migration. 

In 1972 we also recommended instituting sev- 
eral types of controls and audit procedures in- 
cluding: a formal change procedure, the use of a 
librarian software package for controlling dif- 
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ferent versions of a system or application, com- 
piler pre-processors to check for standards viola- 
tions, audits of the documentation system, and 
design review procedures. 

Lientz and Swanson found organizational con- 
trols more widely used than the development 
techniques mentioned earlier. For example, 79% 
of the companies logged and documented users’ 
requests for maintenance, and 77% logged and 
documented changes made. 

These widespread practices did not appear to 
reduce the maintenance effort, say the authors. 
But the practices did indicate where manage- 
ment placed its emphasis—that is, requests were 
logged where companies stressed enhancement 
maintenance. 

The one procedure that reduced corrective 
maintenance (by improving software quality) 
was formal audits of production systems. But 
only one-third of the applications described by 
respondents received such scrutiny. 

And lastly, in 1972 we recommended organiz- 
ing for maintenance. The question has been pon- 
dered whether to perform maintenance work 
within the development group(s) or to create 
separate maintenance groups. Most organiza- 
tions still use a common organization for both 
development and maintenance, partly because of 
their concern over the low morale that might 
occur in a dedicated maintenance group. Man- 
agement believes that most programmers do not 
like maintenance work and will not stay long in 
a maintenance-only group. Reasons _ typically 
given are: maintenance is not challenging, re- 
warding, or creative, and it requires less skill and 
experience. 

Lientz and Swanson found that only 17% of 
the companies responding to their survey had 
separate maintenance groups. Yet these few or- 
ganizations tended to use fewer resources for 
maintenance. These companies also were the 
larger organizations, and larger organizations 
generally spend a larger percentage on mainte- 
nance. So these companies may actually be do- 
ing even better than it first appears. 

Aside from this dilemma, the real issue is not 
which alternative is better, but rather that the 
subject of maintenance be given any serious at- 
tention at all by data processing management. 
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Ignoring the maintenance problem appears to 
make it worse. Establishing specific procedures 
to deal with it seems to ease the burden. 

These then are the recommendations we made 
in 1972 to ease the maintenance workload. The 
major change appears to be that companies now 
have more tools with which they can create 
more maintainable systems. These tools have re- 
duced the need for corrective maintenance in 
newly-created systems but, at the same time, 
they have encouraged enhancement requests 
from users. 


Prospects for easing maintenance 


In light of what has happened during the past 
ten years, here are four steps that can be taken 
to improve software maintenance: fine tuning 
the organization, fine tuning maintenance proce- 
dures, programming for maintainability, and off- 
loading maintenance onto others, either end 
users or package vendors. 


Fine tuning the organization 


In the Lientz and Swanson survey, the respon- 
dents ranked managerial concerns above techni- 
cal concerns, so we will deal with management 
issues first. 

We have come across success stories for sepa- 
rate maintenance groups, combined maintenance 
and development groups, and variations of these 
two approaches. This implies that the type of or- 
ganization may not be the important factor, but 
rather that conscious management attention is. 
Here are some examples of how a few compa- 
nies have eased the software maintenance bur- 
den through fine tuning their organizations. 


A separate maintenance group. One company 
that has had success with a formally separated 
maintenance group is Spring Mills, Inc., a textile 
manufacturer in South Carolina. Mooney (in 
Reference 2) reports that prior to the separation, 
maintenance was not a budgeted item. Develop-_ 
ment projects were interrupted to correct defi- 
ciencies in production programs, make revisions 
caused by changed business practices, and im- 
prove program efficiencies. These were all per- 
formed as needed. Major enhancements to exist- 
ing systems were scheduled along with develop- 


ment work. The staff of forty handled between 
70 and 80 maintenance requests a month. 

The company decided to tackle the mainte- 
nance problem by creating a maintenance team 
of ten senior and junior programmers under a 
project leader. The team was to: (1) log all re- 
quests in and out, (2) evaluate requests and as- 
sign priorities, (3) assign tasks within the team, 
(4) ensure that standards were met and documen- 
tation was upgraded, (5) test new releases of pro- 
grams, and (6) get programs back into pro- 
duction, as quickly as possible. 

Since management feared the team would see 
its work as distasteful, several special policies 
were implemented. Team members were to con- 
tinually and automatically receive the largest 
merit pay raises allowable, they could request a 
transfer after six months, and they would be as- 
signed to write special, one-time programs so 
that their development skills would not deterio- 
rate. 

Management was surprised to find that morale 
throughout the entire department improved 
with the re-organization. The maintenance peo- 
ple became multi-lingual experts, so they were 
respected by their peers in development. They 
learned how not to write programs. And they 
suggested a number of changes to company pro- 
gramming standards and documentation—many 
of which have been implemented. 

The team handled 1000 requests within the 
first year, and allowed the department to handle 
almost 13% more new development work than 
the year before. Maintenance was reduced to 
20% of the department’s total workload, down 
from 30% the year before. A year later a system 
analyst was added to the team, to study how 
planned changes to programs would affect suc- 
ceeding jobs or systems. And new systems are 
now developed with more thought of future 
maintenance than was true in the past. 

Where development and maintenance are or- 
ganized separately, Lientz and Swanson suggest 
using “maintenance escorts.’ An escort is a devel- 
opment programmer who accompanies a system 
when it is transferred to the maintenance group, 
and he or she stays with it until it is absorbed by 
the group. The authors note that this procedure 
takes advantage of the programmer’s knowledge 


of the system and thereby increases the initial 
efficiency of the maintenance group. The con- 
verse of this idea has also been tried—that is, 
moving a maintenance programmer onto a de- 
velopment project to help complete it and es- 
cort it into maintenance. 


Combined maintenance and development. When 
development and maintenance are performed by 
one group, improved maintenance efficiency 
seems to come from instituting more formal 
maintenance practices. 

For example, in the April issue we reported 
on the use of a job diagnostic survey for measur- 
ing job satisfaction among data processing em- 
ployees at one company. A primary point that 
emerged from the use of that survey was that 
the company’s programmer/analysts had strong 
negative feelings about the maintenance work 
they were performing. At the time, each person 
was totally responsible for maintaining one or 
more application systems as well as for perform- 
ing new system development. With users contin- 
ually asking for changes to existing systems, the 
programmer/analysts felt trapped; they were be- 
ing held back from development work because 
of the continual demands for maintenance. One 
change that was made was to assign other pro- 
grammer/analysts to provide backup mainte- 
nance support for each existing system. So the 
maintenance workload was shared. 

In addition, a user liaison position was created 
to be a buffer for maintenance requests, so that 
only relevant requests flowed through to the 
software people. Also, more formal procedures 
for making changes were instituted. Although 
these changes did not reduce the maintenance 
workload, they helped ease it in the eyes of the 
development staff. | 

In light of the fact that there are organizations 
satisfied with each of these different arrange- 
ments, several points can be made. 

First, if maintenance is not to be separated 
from development, then it is necessary to clearly 
define the responsibilities of the staff members, 
so that conflicts between their maintenance. and 
development responsibilities do not create un- 
reasonable pressures. 

Second, the flow of user requests, including 
requests for both ad hoc reports and for en- 
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hancements, needs to be controlled in some 
manner. 

And third, it seems possible to have a part of 
the organization devoted to maintenance with- 
out severe morale problems. It does require 
management attention—but it can be done. 


Fine tuning maintenance procedures 


Numerous practitioners have suggested vari- 
ous ways to add some spice to the maintenance 
function. We will discuss four ideas: scheduled 
maintenance, maintenance reviews, worst-first 
maintenance, and structured retrofit. 


Scheduled maintenance. Lindhorst (in Refer- 
ence 2) describes the benefits that The Boat- 
men’s National Bank in St. Louis has received 
from implementing a scheduled maintenance 
program. They have designated specific months 
for performing maintenance on each of their sys- 
tems. Most requests for maintenance are saved 
and then evaluated and costed during those 
scheduled times. Although the program took 
several months to initiate, and some reshuffling 
of schedules was needed, they now have a main- 
tenance procedure that forces users to think 
more about the changes they request (and their 
associated costs). It also forces data processing 
to periodically evaluate the maintenance costs of 
each system. It has prompted better personnel 
planning in data processing. And it has elimi- 
nated ‘the squeaky wheel gets the grease’ syn- 
drome. Finally it gives data processing requests 
for changes equal consideration with user re- 
quests. 

The bank has found that most changes can be 
postponed and consolidated with others, leading 
to more efficient maintenance. They believe they 
are more in control of their data processing 
workload with scheduled maintenance. 


Maintenance reviews. Freedman and Weinberg 
(in Reference 2) suggest several types of reviews 
to improve the maintenance function. One is 
speed reviews. Here a number of maintenance 
programmers meet together and are given five to 
ten minutes to evaluate a small section of code, 
either for its readability or to find errors. The 
authors find such short, timed reviews are most 
useful. 
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They also suggest maintenance reviews, which 
are separate from the traditional review held be- 
fore transferring development work to pro- 
duction status. If the two reviews are combined, 
as they usually are, maintenance considerations 
are given little attention, since they would delay 
putting the system into production. But if two 
separate reviews are performed, maintainability 
considerations can be given more thought. 


And finally Freedman and Weinberg suggest 
fix and improve reviews. They say these not only 
improve the quality of programs but also in- 
crease the morale of maintenance personnel. 
The objective is to not just fix an error but also 
to improve the software being changed. They 
note that this requires quite a bit of program- 
ming ingenuity, thereby increasing the challenge. 
And if the improvement is limited to the re- 
quested change, maintenance costs do not in- 
crease. They have seen this technique measur- 
ably improve programs (over time), where man- 
agement has made improved software a goal and 
has recognized improvement efforts. 


Based on information uncovered in a recent 
survey, Chapin (Reference 4) reports that most 
of the factors that make programs harder to 
maintain are under control of data processing 
management. In his paper, he lists a number of 
these program attributes, such as arbitrary data 
names, monolithic program structure, and a 
large number of switches and flags. And like 
Freedman and Weinberg, he recommends that 
maintenance managers give programmers the 
time and support to improve the programs they 
maintain which have these attributes. 


Worst first maintenance, as described by 
Weinberg in Reference 2, requires finding out 
where you are spending your maintenance 
money in each system. He has found that often 
80% of the maintenance work is spent on just 
20% of a system. Uncovering this type of phe- 
nomenon does take some data gathering, but he 
notes that such discrepancies are relatively easy 
to spot once you begin to keep track of where 
maintenance people spend their time. He has 
seen several systems greatly improved by uncov- 
ering these ‘worst’ portions and then rewriting 
them to be more maintainable. 


Structured retrofit involves using a software 
product (sometimes called a ‘structuring engine’) 
to analyze a program of ill-defined structure and 
try to convert it into one of ‘well-defined’ struc- 
ture—that is, one that follows certain structured 
programming conventions. The resulting pro- 
gram should produce the same transformations 
on input data as the original program. 


For COBOL programs, we are aware of one 
such product, offered as a service by The Cata- 
lyst Corporation in Brookfield, Illinois, but we 
have not had a chance to talk with users of the 
service. Their service consists of five steps, 
which can be performed at their site or the 
user’s site. (1) First, an operational program sup- 
plied by the user company is put through the 
structuring program. This product cleans up the 
existing language and verb usage and also intro- 
duces a structure to the code. For example, it re- 
duces GOTOs, removes ALTERs, removes dead 
code, and so on. Also, it isolates the control hier- 
archy, highlights looping conditions, and groups 
and standardizes input/output, etc. It does not 
remove logic errors nor produce functional 
changes. (2) Next the restructured source code is 
put through a formatting package to enhance its 
readability. The formatter indents and formats 
code, standardizes paragraph prefixes, field align- 
ment, and reserve words, and so on. (3) Then the 
operational program is recompiled to ensure 
that no syntax errors have been introduced. (4) 
The operational program is next validated by 
running both the old and new versions against 
the same input data. The results are compared 
by a file-to-file comparator package and discrep- 
ancies are analyzed by the supplier’s project 
team. (5) And finally, the validated program is 
run through an object code optimizer to reduce 
the overhead introduced by restructuring. The 
people at Catalyst say their restructured pro- 
grams increase processing overhead by about 8% 
following the optimization step. The company 
then provides a tape of the restructured program 
and suggests ways to further enhance the pro- 
gram. (For more information on the structured 
retrofit concept, see a paper by Miller in Refer- 
ence 2; for more information on Catalyst’s re- 
trofit service, see Reference 7.) 
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Programming for maintainability 


There are several ways to develop programs 
with future maintenance in mind. One way is to 
use development tools which reduce the need 
for corrective maintenance. Use of data manage- 
ment systems, program generators, or applica- 
tion development systems, as described earlier, 
decrease the need for corrective maintenance 
because much of the code is automatically pro- 
duced by such systems. 

Another method is to use structured program- 
ming techniques to improve the quality of the 
software, thereby reducing corrective mainte- 
nance. 

Higgins (Reference 5) discusses the question of 
converting existing ‘unstructured’ programs into 
well-structured ones. He says the idea of a ‘struc- 
ture analyzer, which works on the structure of a 
bad program, only gives a picture of the mess 
that is there. Instead, he advocates taking the 
time to determine the data structures associated 
with the old program and creating a new design 
using those data structures. 

Still another approach is to develop systems 
by prototyping. We will discuss this approach in 
detail next month. The point we want to make 
here is that with prototyping, the users are able 
to actually obtain useful outputs from the sys- 
tem early in its development life cycle, since the 
system functions in a true productive sense but 
in a prototype form. This generally—in fact, al- 
most always—affects the users’ perceptions of 
the system and prompts them to request 
changes—‘enhancements’ in maintenance par- 
lance. These changes are made to the prototype 
through an iterative process, until the user is sat- 
isfied. With the prototyping tool (such as a data 
Management system), these iterations are easily 
and quickly made. The end result is a good def- 
inition of what the production system must per- 
form. 

So prototyping appears to reduce the amount 
of enhancement maintenance requested by users 
for the production system, because so many of 
the changes are captured by the prototype. | 

Yet another approach—which improves the 
general maintainability of programs—is what 
Glass and Noiseux (in Reference 3) and others 
call ‘defensive programming. Like defensive 
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driving, in defensive programming programmers 
design and code with their senses tuned to po- 
tential problems. They write programs which 
have a better chance of detecting problems and 
pinpointing them. Glass and Noiseux describe 
five programming practices that enhance defen- 
sive programming—use of assertions, margins, 
commentary, audit trails, and flagging unsafe 
practices. 

Assertions are statements that a programmer 
can make about the acceptable behavior of a 
program or data. These assertions must be test- 
able. If one assertion fails a test, the program 
prints out a message describing the failure; it 
then either recovers from the failure or aborts. 
(These assertions are not the same as those used 
in proofs of correctness.) For example, an asser- 
tion might be used to detect erroneous or im- 
probable input data, an improper logic flow, or 
an exception condition. The authors’ point is 
that programmers should sprinkle assertion 
statements and tests throughout their programs 
so that they, and the eventual maintainers, can 
monitor a program’s behavior. 

Margins are reserved resources. Programmers 
should not use up all of the available computing 
resources in any of their programs, because then 
new features cannot be added without first free- 
ing up some resources. Programmers should 
leave unused some portion of resources in each 
program—the margins. The authors note that on 
smaller machines, maintainers often spend one- 
half of their time shrinking the amount of re- 
sources used by a program, and the other half 
putting in the new features. This wastes a lot of 
time. 

Commentary. Glass and Noiseux note that of- 
ten the only reliable documentation that a main- 
tainer receives is the program listing. Therefore, 
the listing should be made as complete as possi- 
ble. They suggest placing comments in a pro- 
gram in at least five places: (1) before each sub- 
function, to explain its function, (2) before each 
interface to other modules or programs, (3) be- 
fore each group of related declarations, (4) be- 
fore each declaration, to explain its role and its 
possible values, and (5) before each difficult-to- 
understand portion of the program. These com- 
ments should not only explain what is happening 
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but also why it is happening. Using program de- 
sign language statements may serve this purpose. 

Audit trails. Programmers should also provide 
statements in their programs that help maintain- 
ers track the action occurring in the program. 
During an audit run, these statements would 
record when a module has been entered, asser- 
tions made, when phases have been completed, 
and so on. This facility is most useful when it is 
optional, so that it need not be run for each pro- 
duction run. 

Flagging unsafe practices. The authors note 
that programmers often do use unsafe program- 
ming techniques, and when used, these should be 
flagged. They list a number of such practices. 
One is the use of GOTOs to return to the pro- 
gram following a recoverable exception. These 
flags must be provided by the programmers; 
they are not automatically generated by most 
pre-processors or compilers. 

These then are some suggestions we came 
across for creating software with maintainability 
in mind. 


Off-loading maintenance work 


In the future, we expect data processing de- 
partments to off-load not only some develop- 
ment but also some maintenance work. We see 
this happening in two ways: off-loading work to 
end users and off-loading work to package ven- 
dors by buying application packages. The major 
reasons for using these two approaches may not 
be to decrease maintenance, but that will be a 
side benefit. We briefly look at these possibili- 
ties. 


Off-loading work onto end users. From a main- 
tenance point of view, perhaps the most disturb- 
ing finding of the Lientz and Swanson survey 
was that applications that used a database man- 
agement system or data dictionary grew faster 
than those which did not—indicating that such 
applications probably required more, not less, 
maintenance. With the growing use of database 
management systems, this could mean data 
processing departments will be even more 
swamped with maintenance work. 

Yet, at the same time, DBMS-based tools are 
now available that allow end users to do some of | 
their own programming. So once these tools, 
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and databases, are made available to users, data 
processing may be able to off-load some pro- 
gramming and maintenance work onto these 
other employees. In the May and June reports 
we gave several examples of companies where 
this is actually happening. We believe this is an 
important trend—end user programming. 

From the cases of end user programming that 
we have seen, the responsibility for maintaining 
these applications has not been given to data 
processing; it has stayed with the end users. As 
users do more of their own programming, they 
will also do most of the maintenance required. 


Off-loading work onto package vendors. The 
other way we believe companies will off-load 
software maintenance is by purchasing applica- 
tion packages. With this approach, corrective 
maintenance and some general enhancements 
will be performed by vendors. However, to take 
advantage of this type of package support, pur- 
chasers must be very careful not to invalidate 
their contracts. If a package is changed in any 
manner, the vendor may have legal grounds for 
discontinuing support of the package. One com- 
pany told us that they go to great effort not to 
change a purchased package. If, for some reason, 
changes are needed, they contract with the ven- 
dor to help them perform analysis of the pro- 
posed changes and verify that these changes will 
not invalidate their support. 

The purchase of packages will probably re- 
duce corrective maintenance, and it may reduce 
some types of adaptive maintenance. For exam- 
ple, a main reason why companies purchase the 
ALLTAX package from Management Science 
America (MSA), to use in their payroll programs, 
is so that MSA will make the necessary adaptive 
changes in response to changing government tax 
regulations. The user companies need to main- 
tain the other parts of their payroll programs, of 


course, but tax calculation maintenance is han- 
dled by MSA. | 

Boehm (in Reference 2) estimates that about 
70% of the life cycle programming cost of an ap- 
plication comes from maintenance. With com- 


panies now spending about one-half of their pro- 


gramming time maintaining existing systems, it 
behooves data processing management to stress 
maintainability even more than in the past. 

In this report we have suggested a few ways 
to help maintain older systems, to create more 
maintainable new systems, and off-load some 
maintenance work onto other people. It does not 
look as though program maintenance will go 
away, but there are ways to ease its burden on 
data processing departments. 
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COMMENTARY 


EVALUATING SOFTWARE MAINTAINABILITY 


The need for software maintenance generally makes itself known by some- 
one asking for a change—due to a program error, a change in the hardware 
or operating system configuration, a desired enhancement, or such. We have 
not heard of many cases of where organizations have made a study of their 
software, to rate it as to its maintainability. 


We were pleasantly surprised, therefore, to come across a U.S. Air Force 
project that has developed a methodology for studying existing software and 
rating it as to its maintainability. 


The method is described in Software Maintainability Evaluator’s Hand- 
book, prepared by the Computer/Support Systems Division at the U.S. Air 
Force Test and Evaluation Center, Kirtland Air Force Base, New Mexico, 
87117. It is one of five handbooks developed by this division for use in oper- 
ational testing and evaluation of software. These five handbooks were pre- 
pared for the positions of (1) software test manager, (2) software assessment 
team chairman, (3) software maintainability evaluator, (4) software operator- 
machine interface evaluator, and (5) computer support resource evaluator. 
As the position titles imply, the methodology has been developed for testing 
and evaluating large bodies of software. But it seems to us that a good many 
of the ideas can be applied in computer-using organizations of all sizes. 


The goal of the software evaluator’s handbook is to provide a procedure 
by which members of a team of evaluators can independently evaluate a body 
of software as to its maintainability. Each team member rates the source 
code of each piece of software (programs, modules, or whatever) on up to 89 
characteristics. Further, the documentation associated with each piece of 
software is also rated, on up to 83 characteristics. Further, the statistical 
analysis of the ratings is performed on a computer. So the net evaluation of 
each piece of software, and its documentation, is the product of a team of 
evaluators, rather than the opinions of one or two individuals. 


Once the software has been so evaluated, what then? Although not speci- 
fied in the handbook, the answer seems evident. It is up to management to 
decide what to do about the problems. The poorest programs, from a main- 
tainability standpoint, are generally well known within an installation. Pro- 
grammers often shudder when asked to tackle these. When a number of pro- 
grams have been evaluated, the ‘worst offenders’ probably will show up with 
the lowest ratings. But from the evaluation team’s report, management will 
get an idea of just how bad these programs are, as compared with the others. 


Management should then be in a better position to decide what to do 
about allocating systems and programming resources to clean up the offend- 
ing programs. If prior maintenance costs can be associated with the various 
programs, it may become apparent where clean-up actions (such as discussed 
in this issue) should be taken. 
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But back to the software evaluator’s handbook. As indicated, the method 
considers not only the source code for each piece of software but also that 
software’s documentation. (It is noted in the handbook that the source code 
is often the only documentation available, but it is considered separate from 
the documentation in the methodology.) The documentation consists of the 
program design specifications, program testing information and procedures, 
and the program maintenance information. These documents are evaluated 
both as to their content and their format (for ease of use). 


Both the source listings and the documentation are rated according to six 
characteristics: modularity, descriptiveness, consistency, simplicity, expand- 
ability, and instrumentation (aids which enhance testing). The ratings are per- 
formed by means of ‘questions’. So the method consists of 12 sets of ques- 
tions: the source listings evaluated on the six characteristics and the docu- 
mentation likewise. 


Each ‘question’ really is a statement about a desirable feature of a source 
listing or a document—a feature which enhances or supports maintenance. 
The evaluator is supposed to rate the source listing, or the document, for 
that feature by using a six-value rating scale. An ‘A’ rating means the source 
listing, or document, exhibits the feature in the best possible way. ‘B’ means 
that the feature is used very well; ‘C’ means acceptable, ‘D’ means accepta- 
ble but some improvements should be made, ‘E’ means unacceptable with 
major improvements required, and ‘F’ means the software (or documenta- 
tion) must be completely redesigned. 


The method recognizes that not all questions apply to all pieces of soft- 
ware. An example is given in the handbook: a particular module may not 
have any statement labels. So a question such as “Statement labels have been 
named in a manner which facilitates locating a label in the source listing”’ 
may appear irrelevant for that module. But, in this instance (the handbook 
continues), the software is actually more understandable because there is no 
branching to labelled statements. So the evaluator might well assign a very 
high (‘A’) rating on this question, just as though labels were used that had 
been very well named. 


If you are interested in studying the subject of evaluating software main- 
tainability, this handbook probably would be very useful. You can obtain a 
copy by writing to the Computer/Support Systems Division at the address 
given above. As yet, there is no charge for the handbook. If demand is appre- 
ciable, we would guess that the Air Force would have it distributed through 
the National Technical Information Service. 
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